fix: prevent concatenated gzip response truncation when read via GZIPInputStream - #7331
fix: prevent concatenated gzip response truncation when read via GZIPInputStream#7331jencymaryjoseph wants to merge 1 commit into
Conversation
|
|
||
| public ResponseInputStream(ResponseT resp, AbortableInputStream in, Duration timeout) { | ||
| super(in); | ||
| super(new GzipAvailabilityInputStream(in)); |
There was a problem hiding this comment.
Hmm I don't think this is the right approach; it would make more sense to push the decision of whether this is a GZIP inputstream further down the stack (i.e. closer to the transport/HTTP layer). For example, is there some way we can check the content-type header, and if it's GZIP, wrap the stream there?
Another reason this is problematic is what happens if somewhere down the line we need to make another "workaround" for some other type of content stream?
|
Should we also gate the "always return 1 for GZIP" behavior on something like an Maybe something like |
2 participants
Motivation and Context
When an SDK streaming response body is gzip-compressed and the caller decodes it with
java.util.zip.GZIPInputStream, a concatenated (multi-member) gzip stream can be silently truncated toonly its first member.
Root cause is in the JDK:
GZIPInputStream.readTrailer()decides whether another gzip member follows partlyfrom the underlying stream's
available(). A network-backed response body can transiently reportavailable() == 0exactly at a member boundary (the socket momentarily has no buffered bytes even though moredata is still in flight).
GZIPInputStreamtreats that transient0as end-of-stream, stops decoding, anddrops every remaining member — no error is raised, so the caller just receives partial data.
Modifications
GzipAvailabilityInputStream(@SdkInternalApi,core/sdk-core):1f 8b+ DEFLATE method08).available()as at least1while the stream is open and not atEOF, so
GZIPInputStreamkeeps reading across member boundaries instead of stopping on a transient0.available()through unchanged, so text/line consumers (e.g.BufferedReader) areunaffected.
release()to aReleasabledelegate, and preservesread/skip/mark/reset/closesemantics.ResponseInputStreamnow wraps the bodyInputStreaminGzipAvailabilityInputStreamin bothtimeout-aware constructors. The
abortableis still captured from the original stream, soabort()propagates to the underlying connection unchanged.
Content-Encoding,because that header is not reliably present for gzip payloads and is not available at this layer. Passive
byte detection keeps the behavior change scoped to actual gzip content.
This is intentionally a narrower fix than the previously reverted approach of never returning
0fromavailable()for all streams, which broke incremental line reads (BufferedReader/InputStreamReader). Bydetecting gzip passively, non-gzip streaming is left completely unchanged.
Testing
New tests, plus all existing
ResponseInputStreamtests continue to pass.GzipAvailabilityInputStreamTest(unit):available()coercion for gzip vs. honest pass-through fornon-gzip and near-miss headers (parameterized); bulk-read classification; EOF / closed guards; and regression
guards for zero-length reads, skip-before-classification, mark/reset, and
release()propagation.ResponseInputStreamTest(integration, through the realResponseInputStream): end-to-end decode ofconcatenated and many-member gzip through a real
GZIPInputStreamover a trickle source that reportsavailable() == 0; single-member decode without hanging; a genuinely blocking source that blocks thensignals EOF;
BufferedReaderline delivery on non-gzip content; mark/reset transparency; andabort()propagation through the inserted wrapper.
Screenshots (if appropriate)
Types of changes
Checklist
mvn installsucceedsscripts/new-changescript and following the instructions. Commit the new file created by the script in.changes/next-releasewith your changes.License